其實這一個系列是我對全端可觀測性、監控的30天學習紀錄。在我之前的工作、專案經驗中，要debug就是直接一個一個看console，自己一步一步trace error，同時還可能要加上猜測、驗證、甚至一點點通靈，才能找到一個error的根源。而這樣的trace往往耗時很久、沒有效率。
同時，在近期的一些面試機會中，對於「全鏈路監控」、「可觀測」這個話題其實觸及率蠻高的，所以想要在還沒有入職的這段空白時間裡面，自己好好補上這一個課題。
然後，由於我的技術背景是全端偏前端，所以我預計自己的學習路線會先以前端監控為主、然後帶到opentelemetry的相關library中，進行一系列的demo。不過不知道這樣的內容能否充實到30篇鐵人賽的系列文，但我會努力的！
敲碗 期待 OpenTelemetry
尤其是從 sentry 這知名工具來講。
但我其實有個問題，前端的大大們，會去關心後端服務的狀況嘛？
因為 OpenTelemtry 的目標是串連起來整個端對端的路徑，以及把各種遙測訊號給相互串連。
也就是說可能
FE -> API -> Db -> Redis
-> API 2 -> DB
-> API 3 -> Redis -> DB
然後過程會產生出 trace, log ,metrics等，前端的大大們會去關心後端系統所產生的所有行為嘛 XD
因為我碰過得FE，都是這樣跟我回答，
追蹤？不就 sentry 有。
log 不是 sentry 與 GA都有紀錄一些。
metrics 那啥？ 我只知道 api 很慢。api 很常回 500。
因為如果都不關心這些，好像、似乎就只是換個套件跟console畫面使用 XD
（完成新手任務，可以回覆惹）
的確如雷N大所說的，如果一個團隊的前後端是分得很明確、然後也不是共用同一個監控軟體，那麼前端工程師在職責內的確就是查看前端發生什麼error、或者用戶是如何觸發這個error（user actions）
iThome鐵人賽
看影片追技術